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ABSTRACT 


The Naval Research Laboratory has developed an oceanographic expert system that 
describes the evolution of mesoscale features in the Gulf Stream region of the northwest Atlantic 
Ocean. These features include the Gulf Stream current and the warm and cold core eddies 
associated with the Gulf Stream. An explanation capability was added to the eddy prediction 
component of the expert system in order to allow the system to justify the reasoning process it uses 
to make predictions. The eddy prediction and explanation components of the system have recently 
been redesigned and translated from OPS83 to C and CLIPS and the new system is called WATE 
(Where Are Those Eddies). The new design has improved the system’s readability, 
understandability and maintainability and will also allow the system to be incorporated into the 
Semi- Automated Mesoscale Analysis System which will eventually be embedded into the Navy’s 
Tactical Environmental Support System, Third Generation, TESS(3). 


1. INTRODUCTION 

One of the major reasons CLIPS is so widely used is the ease with which it allows a rule base to be 
incorporated as (me component of a larger system. This has certainly been the case with the eddy 
prediction component of the Semi-Automated Mesoscale Analysis System (SAMAS) (3). SAMAS 
is an image analysis system developed by the Naval Research Laboratory that includes a variety of 
image analysis tools that enable the detection of mesoscale oceanographic features in satellite 
images. Unfortunately, in the North Atlantic, many of the images are obscured by cloud cover for 
lengthy periods of time A hybrid system for use when features cannot be detected in images has 
been developed that consists of a neural network that predicts movement of the Gulf Stream and a 
rule base that predicts movement of eddies associated with the Gulf Stream. The Gulf Stream and 
eddy prediction components woe both originally implemented in OPS83 (4). The Gulf Stream 
Prediction Module has been replaced by a neural network (3) and an explanation component has 
recently been added to the OPS83 version of the eddy prediction component (1). The eddy 
prediction rule base, WATE (Where Are Those Eddies), has been translated to CLIPS because of 
the ease of integrating a CLIPS rule base into a larger system, the ability to access routines written 
in C from CLIPS rules, and the support CLIPS provides for the forward chaining reasoning used 
by the eddy prediction system. The explanation component of WATE uses meta rules written in 
CLIPS to compose either rule traces or summary explanations of the predicted movement of 
eddies. 


1 This work was supported by the Naval Research Laboratory, Stennis Space Cento- under contract NAS 13-330. 
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2. SYSTEM ARCHITECTURE 

2.1 External Interfaces 

The WATE component interacts with other SAMAS components as shown in Figure 1. 
WATE interacts with the User Interface in two ways. First, WATE is invoked from the User 
Interface when the user requests a prediction of Gulf Stream and eddy movement for a specified 
time. Second, as WATE predicts the movement of the Gulf Stream by calling the Gulf Stream 
Prediction Module and eddies by running the rule base, WATE calls User Interface routines to 
update the graphical display of the positions of the Gulf Stream and eddies. The eddy prediction 
rules call the Geometry Routines to compute distances and locations. WATE invokes the Gulf 
Stream Prediction Module to predict the movement of the Gulf Stream for each time step. The 
position of the Gulf Stream predicted by the neural network component must be accessed by the 
eddy prediction rule base since the movement of eddies is influenced by the position of the Gulf 
Stream. 


Figure 1. External Interfaces of WATE 



2.2 Redesigned Control Structure 

The control structure for the original expert system was written in procedural OPS code and 
had been modified a number of times as the graphical user interface, eddy prediction. Gulf Stream 
prediction, and explanation components were either modified or added. The result was a control 
structure that was not modular and that contained a substantial number of obsolete variables and 
statements. When the system was converted from OPS83, the control structure was completely 
redesigned and rewritten in C. Pseudo code for the redesigned control structure is shown in 
Figure 2. The resulting code was more efficient because it was written in compiled C code rather 
than interpreted OPS83 procedural code. 
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Figure 2. Control Structure of WATE 
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2.3 Translation from OPS83 to CLIPS 

The original OPS83 working memory elements and rules had been completely restructured 
to support an explanation component (1). The translation of this restructured OPS83 code into 
CLIPS was fairly simple since CLIPS has evolved from the OK! line. There is a very 
straightforward translation from OPS83 working memory elements to CLIPS fact templates and 
from OPS rules to CLIPS rules. In some cases, the OPS83 rules called OPS83 functions or 
procedures. These functions and procedures were translated to C. 

3. EXPLANATION COMPONENT 

The explanation component allows the user to ask for either a rule trace or summary 
explanation for the prediction of the movement of each eddy at the end of each prediction cycle. 
The rule trace explanations give a detailed trace of the instantiation of all rules that were fired to 
predict the movement of an eddy. Although this type of trace has proven to be very useful in 
debugging the system, it was immediately apparent that it contained a great deal of information that 
would be of little interest to most users. Interviews with domain experts were used to determine 
the information that would be of most interest to a user. The types of information they identified 
was used to design the summary explanations. Presentation of these explanations requires that the 
line of reasoning of the system be captured as the rules fired and that information from this rule 
trace be extracted and organized for presentation to the user. 

3.1 Rule Firing Capture 

Capturing the rule trace for this domain in a usable form is simplified because all 
explanations (both trace and summaiy) are focused on a particular eddy. This means that all of the 
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rule-firings pertaining to the movement of one eddy can be stored together and presented as one 
explanation. This is accomplished by asserting a rule-fire-record template fact for each eddy for 
each time step with the following deftemplate definition: 


(deftemplate rule-fire-record 
(field ringtype 

(field refno 

(field time 

(multifield rules-fired 


(allowed-symbols wcr ccr)) 
(type INTEGER)) 

(type INTEGER)) 

(type SYMBOL))) 


The ringtype, eddy identifier (refno), and time stamp (time) uniquely identify each rule-fire- 
record. The rules-fired multifield is used to store a list of the names of the rules that fired to predict 
the movement of die eddy during this time step. Each time a rule fires as part of the prediction 
process for a particular eddy, the rule name is added to the end of the rules-fired list . 


A second set of template facts is used to record the instantiation of each rule that fires. 
Each time a rule fires, a values-for-explanation template fact is asserted which gives the value 
bound to each variable when the rule was fired. The deftemplate definition for values-for- 
explanation is: 


(deftemplate values-for-explanation 
(field rule-name 

(fidd ringtype 

(fidd refno 

(field time 

(multifield var-val 


(type SYMBOL)) 
(allowed-symbols wcr ccr)) 
(type INTEGER)) 

(type INTEGER)) 

(type SYMBOL))) 


This template contains slots for the rule name, the eddy identifier and type, and the time stamp. In 
addition, it contains a multifield slot whose value is a sequence of variable value pairs that gives the 
name of each variable used in the rule-firing and the value bound to that variable when the rule 
fired. This approach can be used in this domain because a angle rule will never fire more than 
me time for a particular eddy during one time step, and all dots in templates used by the eddy 
prediction rules are single value. The records of the rules that fired for a particular eddy are used 
by meta rules to produce the explanations. 


3.2 Explanation Construction and Presentation 

If the user requests an explanation for a specific eddy, a set of explanation meta rules are 
used to construct an explanation for the predicted movement of an eddy. The user may request 
either a rule-trace explanation or a summary explanation. When the user makes the request, a 
sequence of explain-eddy facts for that eddy are asserted each with a progressively higher time 
stamp. The fact template for an explain-eddy fact is: 


(explain-eddy ccr | wcr <ref-no> <time> summary 1 rule-trace). 

The presence of this fact causes the explain-single-eddy rule to fire one time for each rule that fired 
to predict die movement of the eddy for that time step. Each explain-single-eddy rule firing 
matches a rule name from the rules-fired slot of the rule-fire-record with a values-for-explanation 
template for that eddy type, number, and time stamp. A fill-template fact is then asserted into 
working memory which contains all of the information needed to explain that rule firing— either in 
rule-trace or summary form. For each rule, there are two explanation meta rules. The first is used 
when a rule-trace has been requested and is a natural language translation of the rule. It will give 
the value of all variables used in the rule instantiation. The second is used when a summary has 
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been requested It gives a much shorter summary of the actions of the rule. A few rules that are 
used to control the sequence of rule-firing produce no text for a summary explanation. When an 
explanation metarule fires, it causes a natural language translation of the rule to be sent to the user 
interlace for presentation to the user. 

The user may request an explanation of the movement of all eddies instead of just a single 
eddy. In this case, the process above is simply repeated for each eddy. 

4. SUMMARY AND FUTURE WORK 

WATE has been successfully converted from OPS83 to C and CLIPS. This conversion 
will facilitate the incorporation of WATE into SAMAS 1.2 which will eventually be embedded in 
TESS(3). The modular control structure of WATE is easier to understand and maintain than that of 
the previous system. The explanation component has been implemented using CLIPS metarules. 
This causes some additional maintenance burden since the two metarules that correspond to each 
rule must be modified if a rule is modified. In the present system, the rule-fire-record and values - 
for -explanation template facts are asserted by each individual rule. We are currently modifying the 
CLIPS inference engine to capture this information automatically as the rules fire. 

Explanations produced by the current system have two major shortcomings. First, there is 
still a great deal of room for improvement in the summarization capabilities of the system. In 
particular, the system should be summarizing over both temporal and spatial dimensions. If an 
eddy’s predicted movement is essentially in the same direction and speed for each time step, then 
all of this information should be collapsed into one explanation. Likewise, if several eddies all 
have similar movement over one or more time steps, this should be collapsed into a single 
explanation. The second shortcoming deals with the lack of explanation of the predictions of the 
neural network component. Some recent results reported in the literature have addressed this sort 
of problem. 
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